The Universal Serial Bus (USB) is a cable bus that supports data exchange between a host computer and a wide range of simultaneously accessible peripheral devices. The attached peripheral devices share USB bandwidth through a host-scheduled, token-based protocol. The bus allows peripherals to be attached, configured, used, and detached while the host and other peripherals are in operation.
The USB is defined by a specification that is approved by a committee of industry representatives. The specification covers all aspects of USB operation, including electrical, mechanical, and communications characteristics. To be called a USB device, a peripheral must conform to this very exacting specification.
USB device information is typically stored in so-called “descriptors” or request codes—data structures formatted as specified by the USB specification. Descriptors are used in a USB system to define “device requests” from a host to a peripheral device. A device request is a data structure that is conveyed in a “control transfer” from the host to the peripheral device. A control transfer contains the following fields:                bmRequestType—a mask field indicating (a) the direction of data transfer in a subsequent phase of the control transfer; (b) a request type (standard, class, vendor, or reserved); and (c) a recipient (device, interface, endpoint, or other). The primary types of requests specified in the “request type” field are the “standard” and “vendor” types, which will be discussed below.        bRequest—a request code indicating one of a plurality of different commands to which the device is responsive.        wValue—a field that varies according to the request specified by bRequest.        wIndex—a field that varies according to request; typically used to pass an index or offset as part of the specified request.        wLength—number of bytes to transfer if there is a subsequent data stage.        
All USB devices are supposed to support and respond to “standard” requests—referred to herein as “USB-specific” requests. In a USB-specific request, the request type portion of the bmRequestType field contains a predefined value indicative of the “standard” request type.
Each different USB-specific request has a pre-assigned USB-specific request code, defined in the USB specification. This is the value used in the bRequest field of the device request, to differentiate between different USB-specific requests. For each USB-specific request code, the USB specification sets forth the meanings of wValue and wIndex, as well as the format of any returned data.
USB devices can optionally support “vendor” requests—referred to herein as “device-specific” requests. In a device-specific request, the request type portion of the bmRequestType field contains a predefined value to indicate a “vendor” request type. In the case of device-specific requests, the USB specification does not assign request codes, define the meanings of wValue and wIndex, or define the format of returned data. Rather, each device has nearly complete control over the meaning, functionality, and data format of device-specific requests. Specifically, the device can define its own requests and assign device-specified request codes to them. This allows devices to implement their own device requests for use by host computers, and provides tremendous flexibility for manufacturers of peripherals.
The inventors have discovered a need for a similar feature that would benefit various hosts, application programs, host operating systems, hardware manufacturers (OEMs), and Independent Hardware Vendors (IHVs). Specifically, designers of application programs and operating systems would value the opportunity to define their own device requests (and the associated responses), and to have such requests supported in a uniform way by compatible peripherals. Moreover, OEMs and IHVs (makers and distributors of USB devices) would value the ability to supply additional USB device-specific information to the hosts, application programs and host operating systems in response to such device requests. However, the different request types supported in the bmRequestType field of a USB device request do not include a “host” type of request.
As an example of this need for a host type of request, consider that a typical USB device installation scenario typically involves customer use of installation media such as OEM/IHV supplied installation disks (e.g., a floppy disk) and/or setup computer program applications. Such installation media are generally shipped with the device or made available over the Internet. Installation media typically provide device-specific settings and resources such as: (a) a device driver to control the device; (b) one or more user interface elements; and (c) an information file (e.g., an “.inf” file) to specify names and locations of the setting and resources. Such user interface (UI) elements include, for example, icons, fonts, pictures, labels, help pages, Universal Resource Locator (URL) Internet links, and the like.
Upon installation, a USB device typically provides an operating system with USB standard class and subclass codes, which are used to determine whether a generic, or default device driver can be used to control the device. If so, a special OEM/IHV supplied device driver may not be necessary to control the device. Thus, it is often unnecessary for customers to install the device drivers provided by the installation media for the device to function properly upon being attached.
However, as USB devices gain popularity, OEMs/IHVs typically want to load other device-specific brand information to allow an operating system to present a shell or user interface information that is appropriate to a particular USB device. Such information includes brand icons, fonts, pictures, labels, help pages, Universal Resource Locator (URL) Internet links, and the like. Thus, even though an installation media supplied device driver may not be required, an installation media including an information file still typically needs to be distributed with the device to specify any device-specific shell or user interface information. (Hereinafter, “shell” and/or “user interface” information is often referred to generally as “user interface”, or “UI” information).
One of the benefits of using a USB device is to reduce the amount of interaction typically required of a user to attach and configure a device. This ease of use has typically reduced the amount of device installation related customer support that OEMs/IHVs have needed to provide. Thus, when a default device driver can be used to control a device, it would be beneficial (both in terms of customer ease of use and in terms of the amount of customer support typically required) if installation media such as installation disks or setup programs were not required to be distributed to specify device-specific UI information. Rather, an operating system could query a device for this additional device specific information. Unfortunately, because host-specific USB requests are not provided or considered by the USB specification, there are no standards that allow a vendor to provide additional USB device-specific information in a USB device in a format that is determined by an operating system.
Accordingly, the invention arose out of concerns associated with providing a host-specific device request that solves the problems described above.